Authentication Events API V2

#1

I’m currently implementing the Events API V2, and what I find striking is that the only form of “authentication/authorization” is the routing key. I would expect some kind of authorization header (which is present for the REST API).

In my use case security is of high importance and if someone would make a typo in the routing key I have the feeling that this could potentially end up at an organisation that should have never gotten this alert. Our idea is to have several (~10) routing keys, and a mistake can easily be made.

Am I overlooking something or is this in fact the only form of authentication and authorisation?

#2

Hi Jan,

We recommend copying/pasting rather than typing out the tokens to help prevent such issues from occurring. I can understand your concern about the Events API V2 and have submitted a Feature Request to our Product team. I will share the concerns that you have provided to our team.

Thanks,

Abbott Brannon
Technical Support Specialist

#3

Hi @abbott,

thanks for getting back to me, indeed copy pasting the key will prevent it. The mistake is however still easily made.

Amongst that I also feel that this opens the door for other people to:

  1. Acknowledge alerts that we’ve created
  2. Perhaps request data through GET calls
  3. Not sure about uniqueness of the routing key, although very unlikely (not sure whether guaranteed from your end) I could have the same key as another organisation has. What would happen in that scenario

What would work best for me is similar like the REST API that we have authentication using the API token/key and the routing key is purely for that, nothing more.

Would be great if you can provide insights on how likely this will be implemented, and if implemented what rough timeline I should account for.

#4

Hi Jan

We would not have insight into timescales as to when it will be implement. Your feedback has been passed along to the Product Team who will review the feedback. Based on customer impact, they will prioritise the feature request accordingly then begin the planning process for design and development.

Please let me know if you have any other questions or feedback regarding this request.

Cheers,

#5

Hello,

According to Jan concerns, it’s not only about typo/mistake but also how to guarantee someone can’t send events to our PagerDuty instance by generating random values for the routing key (and find a real routing key value).

Can you provide some information about how do you deal with that?
And also for the mail integration.

Regards,
SĂ©bastien

PS: if this topic is not the right place for this question, please let me know and I will open a new one.

1 Like
#6

Hello Sebastien,

Having a form of authentification is what has been logged as a feature request with the Product Team.

Meanwhile for now, it would help ensure email integrations are not cc’d in on external emails and integration keys are not exposed. That is mostly how people outside an organisation get access to the integrations as they are randomly generated.

I hope that helps.

Kind regards,